Summary This portal was built for Invoke, a Texas-based Microsoft partner. The wider engagement, covering Dynamics 365 Project Operations, Power BI reporting and QuickBooks integration, is described in our Invoke case study. A customer portal that filters records only in page code exposes data the moment someone calls the Web API directly. We built a role-based customer portal in Microsoft Power Pages where Dataverse table permissions decide access, and Liquid with FetchXML only shapes the view. One Service Requests page now serves three user scopes. Global users see every request, department users see their department’s requests, and regular users see their own. Contacts from the same account share that account’s subscriptions, contracts, projects and invoices. Dashboard tiles use aggregate queries scoped the same way as the lists, and search and paging run on the server at ten rows per request. This Blog Explains How web roles and table permission access types map to global, department and personal visibility How one Liquid template with a FetchXML query replaces a separate page per role How the Account access type gives every contact in a customer organisation the same subscriptions, contracts, projects and invoices How aggregate FetchXML keeps dashboard counts in step with the lists behind them How a negative test through the Web API proves the security model before go-live Introduction For a portal user, the question “Which service requests can I see, and why can my colleague see more?” should have one answer, wherever they ask it. In a portal built page by page, the answer changes with the route. The list page hides a row, the details page opens it from a pasted URL, and the Web API returns it without complaint. Power Pages gives a developer two places to apply a visibility rule. One is the page, through Liquid and JavaScript. The other is Dataverse, through web roles and table permissions. Only the second one follows the user to every list, form and API call. This post covers how we used both, each for the job it suits, and the two points where our first design was wrong. Table of Contents Summary→ The Business Problem→ The Solution→ Technical Approach→ Business Impact→ Conclusion→ Ready to Build a Secure Customer Portal?→ The Business Problem The portal had to show each signed-in contact the right slice of Dataverse without a separate page per audience and without trusting the browser. Service requests have three audiences. Subscriptions, contracts, projects and invoices belong to a customer account, and several contacts from that account need the same view of them. When each page carries its own filtering logic, four recurring problems appear: Duplicated pages: A Service Requests page per role means three templates, and every new column is added three times Security that lives in the template: A Liquid if hides rows on one page and does nothing for another list, a basic form or a /_api/ call from the browser console Counts that disagree: Dashboard tiles built with their own queries show numbers the user cannot reproduce by opening the list Slow lists: Loading every case and filtering in JavaScript works in testing and degrades once the table holds thousands of rows The Solution We designed around one rule: Dataverse decides what a contact may read, and the page decides how to present it. Every visibility requirement had to be expressed as a table permission first. Liquid and FetchXML then narrow and arrange what the permission already allows. IdentitySigned-in contactAuthenticated through the portal identity provider RoleWeb roleGlobal Users, Department Users or Regular Users SecurityTable permissionsGlobal, Account or Contact access type per table QueryLiquid and FetchXMLOne query, filter chosen by role PageList and dashboardTen rows per request, counts from aggregates For a business user the result is plain. Two people from the same customer open the Invoices page and see the same invoices. A person from a different customer sees none of them, whichever route they use to ask. The sections below explain how each part closes a gap in the page-by-page approach. Figure 1: Portal sign-in page. Each user authenticates as a contact before any web role applies. Technical Approach We built in a fixed order: permissions first, queries second, interaction last. A query written against an open table hides permission gaps until late, so the table permissions were configured and tested before any web template existed. 1. Web Roles and Table Permissions as the Security Boundary Each portal user is a contact, each contact holds one or more web roles, and each web role carries table permissions. A table permission names a table, a privilege such as Read, and an access type. Power Pages offers Global, Contact, Account and Self access types, plus child permissions that inherit from a parent table. Web role Table Access type Record must relate to Global Users Case (incident) Global Nothing, all rows are readable Department Users Case (incident) Account The contact’s parent account through the case customer Regular Users Case (incident) Contact The signed-in contact as primary contact on the case All three roles Subscription, Contract, Project, Invoice Account The contact’s parent account Table 1: Read permissions configured for this portal. Create and Write were granted separately and only where a form needed them. 2. Where a Department Lives in the Data Model Power Pages has no Department access type, so a department has to be expressed as something the permission model understands. Our first design used a custom department lookup on the case, a Global permission for department users, and a FetchXML condition to narrow the rows. It rendered correctly and failed the first negative test, because the Web API ignored the page filter and returned every case. Criteria Global permission plus Liquid filter Our choiceDepartment as an account record Page shows only department rows ✓ ✓ Web API call returns only department rows ✗ ✓ Other lists and forms inherit the rule ✗ ✓ No change to the Dataverse data model partial ✗ We reversed the decision and moved departments into the account hierarchy as … Continue reading How We Built a Role-Based Customer Portal in Microsoft Power Pages for a US-Based IT Services Provider →

Summary A client asks for a project update, and the project manager starts a tour of SSRS reports, Power BI pages and notes before anything reaches a slide. We built a client-ready project report that comes from one page in our custom Project Hub. One button downloads a paged PDF with the project summary, hours, utilization and progress, drawn in the browser with jsPDF. Table of Contents Summary→ Business Challenges→ Solution Overview→ Solution Approach→ Impact→ Conclusion→ Next Step→ Business Challenges For most project managers, a client update means collecting the same figures from several places, every time. Open the reportsClick through to an SSRS report for task status, then a Power BI page for utilization and hours. Read and noteCopy budget, consumed hours, remaining hours and progress into notes, one project at a time. Stitch the documentPaste the figures and screenshots into PowerPoint or Word and shape them for the client. Check it againMake sure the totals in the deck still match the reports before it goes out. The work repeats for every client and every reporting cycle. A new figure the client wants usually means one more report to design and publish before the PM can even copy it. ⓘWhat a PM really needs One view of the project, and one document the client can read without a walkthrough. Solution Overview Not anymore. The PM opens the Project Dashboard in our Project Hub, reads the whole project on one page, and presses PDF. A complete, paged report downloads a moment later. 1 PDF builds the report from what is on screen The PDF button sits next to Copy and CSV. Why not print the dashboard to PDF? A screen print looks like a shortcut until you see it on paper. Charts split across pages, buttons and filters print with the data, and wide tables lose their right edge. A PDF made from screen images also has no selectable text, so the client cannot search it or copy a figure. We took a different route and drew the report ourselves, page by page, with a free library called jsPDF. Think of it as laying out a printed page by hand: each heading, table and figure sits in a set place, so the result reads like a report someone designed. What does the client-ready project report include? Each report follows the same order, so a client knows where to look from the second report onwards. A title block with the date and the scope: projects, any task filter and which hours count. A summary panel with budget, consumed, remaining or over, utilization, and a stacked bar of approved, submitted and other hours. Per project: the name with a health pill, six key figures, a progress bar with a budget mark, and a task table. A "Tasks utilization by resources" table, monthly hours, and a "Page n of N" footer. The PM installs nothing and opens no other tool. The report builds itself in the browser from the figures already on the page. Solution Approach Behind the button sits a simple idea: take the numbers the PM already trusts on screen and set them on paper the way a client wants to read them. What happens when the PM presses PDF? Pick the projectsThe PM selects one project or several in the Project Dashboard, with any task filter they need. Reuse what is on screenThe Hub takes the budget, hours, utilization and status it has already loaded from Dynamics 365. Nothing is retyped or copied. Lay out the pagesThe Hub writes the title, summary and one section per project onto A4 pages, adds page numbers, and repeats table headings when a table runs onto the next page. Download and sendA PDF lands in the PM’s downloads, ready to attach to an email or share in Teams. 1 2 3 One summary for everything selected Health at a glance for each project Who worked on what, by hours Page 1: the scope, the summary across all selected projects, and the first project sections. Each project gets the same layout: a health label, six key figures, a progress bar and the task table. A client reading the third report finds things where they found them in the first. How does this compare with the usual options? Criteria Screen print to PDF A separate SSRS or Power BI report Our choiceOne-click PDF from the Project Hub Reads well on paper ✗ ✓ ✓ Client can search and copy figures ✗ partial ✓ Same numbers the PM sees on screen ✓ partial ✓ No extra report to build and maintain ✓ ✗ ✓ Clicks to a client-ready file Several Several 1 A separate report can look good, but it needs its own design and its own copy of the project rules. The Hub PDF uses the rules the dashboard already follows, so the two never drift apart. What we learned along the way ▤Design for paper firstA layout that works on a wide screen rarely works on A4. We planned the page before we placed a single number. ↔Give every number its own spaceFigures and labels each have a fixed column, so a long status never sits on top of a percentage. ⧉Repeat headings on each pageWhen a task table runs onto the next page, its column titles come with it, and every page says Page n of N. ◎Look at every page before releaseEach change to the layout goes through a check that saves the PDF and turns each page into an image we review by eye. 💡Next on our list A project section that does not fit the bottom of a page will move to the next page as one piece, so its tables always stay together. Impact The PM goes from question to client-ready report without leaving Dynamics 365. 1 pageTo read the whole project in the Project Hub 1 clickTo download the client-ready PDF 0Extra SSRS or Power BI reports to build Page n of NNumbered footer on every page Before … Continue reading From Scattered Reports to One Click: A Client-Ready Project Report Inside Dynamics 365 →

Summary Prophet is a forecasting method from Meta’s Core Data Science team. It works well for business numbers that follow repeating patterns, such as retail sales, website traffic, and revenue. This blog explains where Prophet helps, why it is easy to understand and use, and when it needs extra care. Table of Contents 01 Introduction 02 Retail Sales Forecasting: Planning for Demand 03 Forecasting Website Traffic and Infrastructure Needs 04 Forecasting Business Numbers: Growth and Operational Trends 05 Why Use Prophet? 06 When Prophet May Not Fit Well 07 Making Forecasts Useful for the Business 08 FAQs 09 Conclusion Introduction Every organization generates data. Sales, customer activity, website traffic, daily operations, and system usage all build up a history over time. The value of this data is not only in understanding what happened yesterday. It is also in preparing for what may happen next and making better decisions today. This is where forecasting is useful for business leaders. Prophet, developed by Meta’s Core Data Science team, is a practical way to forecast business numbers that follow repeating patterns, seasonal changes, and changing growth. However, Prophet is not suitable for every forecasting problem. How well it works depends on the business problem, the past data available, and the decisions the forecast will support. Where Prophet Can Help 1 Retail Sales Plan stock, purchasing and delivery around weekly, seasonal and holiday patterns. 2 Website Traffic Forecast visits and usage to plan how much system capacity is needed. 3 Business Numbers Forecast revenue, new customers and user growth for planning. 1. Retail Sales Forecasting: Planning for Demand Retail demand changes throughout the year. Sales are affected by weekly shopping habits, seasons, promotions, and holidays. These patterns directly affect inventory, purchasing, delivery planning, and revenue expectations. A 2020 research study, Application of Facebook’s Prophet Algorithm for Successful Sales Forecasting Based on Real-world Data, used Prophet on actual sales data from a large retail company in Bosnia and Herzegovina. The study showed how Prophet, together with testing on past data, can be used to forecast retail sales and check how reliable the forecast is for different products. Why Prophet Makes Sense Seasonal patterns: Retail sales often rise and fall on weekly and yearly cycles, and Prophet can include these. Holidays: Known holidays and special events can be added to the forecast. Changing trends: The forecast can allow sales trends to change instead of assuming steady growth. Many products: The same approach can be used for many products. The reliability of each product’s forecast should be checked separately. The goal is not only to predict sales. It is to help the business make better decisions about stock availability, purchasing schedules, delivery planning, and cash planning. A forecast is useful when it connects directly to a business decision. 2. Forecasting Website Traffic and Infrastructure Needs Websites and online platforms produce operational data all the time. Website visits, app usage, and system load often follow patterns based on weekdays, weekends, seasons, and business events. Meta’s original work on Prophet aimed to make business forecasting easier to use at a larger scale, including forecasting the numbers used to plan how much system capacity is needed. One example is using past website traffic to forecast future demand. The aim is to understand how traffic is likely to change and whether the current infrastructure can support it. Why Prophet Makes Sense More than one pattern: Daily traffic can follow both weekly and yearly patterns. Changing growth: Growth can change as products change or more people start using them. Capacity planning: Forecasts help infrastructure teams plan for future needs. Spotting differences: Forecasts can be compared with actual traffic to notice unexpected changes. For leaders, the benefit is linking the forecast to infrastructure spending decisions. Instead of relying only on past peak usage or reacting once demand rises, teams can use forecast demand as one more input when planning capacity. This is helpful when cost, system performance, and customer experience all need to be balanced. 3. Forecasting Business Numbers: Growth and Operational Trends Organizations regularly track numbers such as revenue, new customers, user activity, and operational volumes. Prophet was designed to support business forecasting at larger scale, including numbers such as revenue and user growth. These numbers often show repeating patterns, an overall growth trend, and changes caused by business events. Why Prophet Makes Sense Easy to understand: The trend and seasonal parts of the forecast make it easier to read and explain. Changing growth: It can handle growth that speeds up or slows down over time. Known business events: Events such as product launches can be included when their effect is described properly. Easy to review: Business teams can look at the trend and seasonal parts instead of receiving only a final number. This is useful when forecasts need to be reviewed and understood by finance, operations, and leadership, and not only by the data team. The forecast can support revenue planning, growth estimates, resource allocation, and operational reviews. One thing to keep in mind: a forecast of a business number does not explain why that number is changing. Understanding the effect of pricing, marketing campaigns, customer behavior, or other business factors may need additional analysis. Why Use Prophet? Prophet builds a forecast from parts of the past data: the trend, the seasonal patterns, and the effect of holidays and events. These parts reflect patterns that are common in business data, and they do not require a lot of manual setup. What Prophet Looks At The parts of past data that shape a Prophet forecast 1 Trend The general direction of the numbers over time. 2 Weekly patterns M T W T F S S Repeating changes across the days of the week. 3 Yearly patterns Jan Dec Repeating changes across the seasons of the year. 4 Holidays and events Known dates, such as holidays or product launches, that affect the numbers. From Past Data to a Business Decision 1 Past Business Data Sales, traffic, revenue or other numbers. 2 Prophet … Continue reading Forecasting with Prophet-When Does It Make Sense →

Correcting Receipt Costs Before Inventory Closing in Dynamics 365 Finance & Operations Summary Inventory closing in Dynamics 365 Finance & Operations settles issues against receipts. If a receipt carries the wrong cost, closing pushes that error into cost of goods sold and closing stock value. The client is a multi-country oil & gas and marine services provider, serving exploration and production operators from offices across the Middle East and Asia. They run Dynamics 365 Finance & Supply Chain Management for accounting, procurement, project management and inventory, with Power BI on top for reporting. During a month-end support engagement we found one receipt valued at a fraction of an identical earlier receipt. We corrected it through a transaction adjustment, recalculated the item, checked ageing and only then ran closing. The fix itself takes minutes. The order of the steps is what matters. Table of Contents 1. Business Challenges 2. Solution Overview 3. Approach & Methodology 4. Impact 5. FAQs 1. Business Challenges We found two receipts of the same item, at the same site and warehouse, for the same quantity of 5. Their values were far apart. Receipt Quantity Posted value Value per unit Receipt 1 5 23,050.15 4,610.03 Receipt 2 5 1,375.00 275.00 Same item, same site and warehouse, same quantity. If we had run closing on these values, two things would have happened. Every issue settled against the second receipt would have been settled at too low a cost, understating cost of goods sold. Inventory value at month-end would have been understated. 2. Solution Overview Closing uses the cost on each receipt to settle and adjust issues. When we correct the receipt first and then recalculate, D365 re-costs the dependent issues for us. Correcting after closing is more work. It means reversing the close or posting further adjustments in a later period. The sequence we follow: Correct the cost, recalculate the item, check ageing, then close. 1 Correct cost Transaction adjustment 2 Recalculate Re-costs dependent issues 3 Check ageing Confirm values flow through 4 Close Run on correct values Fix the receipt before anything settles against it. Reversing this order later means a reopened period. The correction sequence: cost first, then recalculation, then an ageing check, and only then closing. Reverse that order and a quick fix becomes a reopened period. 3. Approach & Methodology 1. Correct the item cost through a transaction adjustment Go to Inventory management > Periodic tasks > Closing and adjustment. Open a transaction adjustment. On the action pane, select Adjustment > Transactions. An adjustment voucher opens, dated the month-end. Choose the transactions. Select Select to choose the transactions to adjust. Filter by item. In the query, enter the item number in Criteria against the Item number field. Add other ranges such as financial date if needed, then select OK. Enter the correct unit cost. The item’s open receipts load with posted quantity and posted value. Select Adjustment > Item cost price and enter the correct unit cost. The Adjustment column shows the change per line. Post. Select Post. Recalculate the item. Run an item-wise Recalculation from Closing and adjustment, dated the month-end, so dependent issues pick up the corrected cost. Inventory management  ›  Periodic tasks  ›  Closing and adjustment Adjustment ▾Close procedure ▾RecalculationInquiries AdjustmentTransactions Voucher dateMonth-end Adjust transactions, query filtered by item number Receipt Posted qty Posted value Item cost price Adjustment Receipt 1 5 23,050.15 4,610.03 No change Receipt 2 5 1,375.00 4,610.03 +21,675.15 Posted, ready for recalculation Illustrative mockup of the Closing and adjustment / Adjust transactions flow, not an actual product screenshot. The item cost price adjustment lands on the under-valued receipt line and shows the resulting adjustment amount. 2. Check inventory ageing Review the inventory ageing report as on the month-end date. Confirm the corrected values flow through. Inventory management  ›  Inquiries and reports  ›  Inventory ageing CalculateExport ▾PrintInquiries As of dateMonth-end Item numberFiltered Inventory ageing by value as on the month-end date Item Qty on hand 0–30 days 31–60 days 61–90 days Total value Item (same item) 10 46,100.30 0.00 0.00 46,100.30 Corrected value flows through, both receipts now aligned Illustrative mockup of the Inventory ageing inquiry, not an actual product screenshot. After the adjustment and recalculation, the second receipt’s value lines up with the first and total inventory value is correct. 3. Run inventory closing In Closing and adjustment, select Close procedure > Close, set the month-end date and run it. Confirm the new closing line shows OK, and review the log if it has warnings. Inventory management  ›  Periodic tasks  ›  Closing and adjustment Close procedure ▾Adjustment ▾RecalculationInquiries Closing nameMonth-end close Closing dateMonth-end Close procedure > Close: closing run history Closing Closing date Run type Status Prior period Previous month-end Closing Closed Month-end close Month-end Closing Closed OK Closing completed with no errors in the log Illustrative mockup of Close procedure > Close, not an actual product screenshot. The closing run completes with status OK once it runs on the corrected receipt values. 4. Impact Before Correct after closing Issues settled at too low a cost flow into cost of goods sold Month-end inventory value is understated Fix needs a close reversal or later-period adjustments Rework in the next period After Correct before closing Receipt cost fixed through a transaction adjustment Recalculation re-costs dependent issues automatically Closing runs on correct receipt values Minutes of checks before close Practical takeaway Make a receipt-cost check part of your pre-closing routine. Look for receipts of the same item whose value per unit is far out of line with earlier receipts. Correct them through a transaction adjustment, recalculate, then close. 5. FAQs 1. Why not just correct the cost after closing? Because closing has already settled issues against the wrong receipt cost. Fixing it afterwards means either reversing the close or posting further adjustments in a later period. Both take far more work than a check before you close. 2. What does recalculation do that closing does not? Recalculation re-costs the dependent issues using the corrected receipt cost without finalising … Continue reading How a Multi-Country Oil & Gas and Marine Services Provider Corrected Receipt Costs Before Inventory Closing in Dynamics 365 Finance & Operations →

Summary Our client is a US-based manufacturer of premium connected countertop cooking appliances, sold direct to consumers and through retail partners. Their in-house support team works warranty, returns and device troubleshooting cases in Dynamics 365, but the rules for handling those cases lived outside it, in documents that had to be opened in a second tab. We built what they call the troubleshoot guide using the side pane, a part of the app shell most implementations never touch because the out of the box app only uses it for the productivity pane and the Copilot panel. A Quick Reference Guide icon in the right-hand rail opens a business rules library beside the record, it stays open while the agent moves from one case to the next, and it is edited in place by the people who own the rules. The content sits in Dataverse rows instead of in a solution, so adding or correcting a rule is a data change rather than a deployment. This post covers why we chose that surface, the two design calls we reversed mid build, and the limits we would design around on a second pass. ⓘPart of a wider engagement The troubleshoot guide is one piece of a longer programme of Dynamics 365 enhancements, reporting and third-party integrations for this client. Read the full Customer Success Story. Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ Let’s Talk→ Business Challenges The problem was never that the rules did not exist. The problem was where they sat relative to the work. The handling rules lived in documents outside CRM, so finding the right paragraph meant leaving the case form and giving up the record context Rules changed more often than anyone could republish them, and a correction had to go back through whoever owned the file Nothing tied a rule to the moment it was needed. The agent already had the case open and still had to remember which policy applied Anything that put the content on a form tab would have turned a typo fix into a customisation, an export and an import ⚠The cost was the switch, not the search Opening a document is quick. Rebuilding where you were in a case after you come back is not, and that happened on every lookup. Solution Overview The troubleshoot guide is a side pane. Most users only ever meet that surface as the productivity pane in Customer Service, and most project teams reach for a dialog or a form tab because those are the shapes everyone already knows. The pane is the only one of the three that keeps the reference material and the record on screen together. The entry point is a Quick Reference Guide icon in the right-hand rail of the app. It is there as soon as a case is opened and on a case the agent is still creating, so somebody taking a call does not have to save the record first. The launcher sits in the right rail, available on an open case and on a new one. One click opens the pane, and it stays pinned as the agent moves to the next record. Content is organised in two levels: a business rule heading, and sub-sections under it, all collapsed when the pane first renders so the agent sees the index before the detail. The pane in the right column of the app shell, beside the live form. What the pane does Two level structure. A business rule heading holds any number of sub-sections. Everything renders collapsed, so the agent reads an index first and opens only the rule they need Search across both levels. One box matches heading names and the body text of every sub-section at the same time, and auto-expands whatever it hits. Clearing the box restores exactly which sections were open before the search started Inline authoring. Add a heading, add a sub-section, write bold text, colour a warning line, insert a link. No second screen and no admin rights Insert images two ways. Upload from the device, or point at an existing URL. Either way the image is resized and compressed before it is stored Paste from Word and Outlook. The rule owners draft in Word. Pasted formatting is cleaned on the way in, and a screenshot sitting in the clipboard is embedded as part of the same paste Sort by dragging. Headings reorder against each other, sub-sections reorder within their heading, and the new position is saved the moment the item is dropped Move a sub-section to a different heading. Drag it out of one section and onto another. A collapsed heading opens itself when the item hovers over it, so nothing has to be expanded first Light and dark themes. A toggle in the pane header, remembered per browser, because the pane is open all day beside a form whose theme the agent does not control Delete that deactivates. Removing a heading deactivates its sub-sections first, then the heading, so nothing is orphaned and nothing is destroyed ⓘNothing here is a customisation Every heading and every sub-section is a Dataverse row. Publishing a new rule does not touch the solution and does not need a developer. Technical Approach Why the side pane and not a form tab We looked at three places to put the guide before writing anything. The deciding criterion was not how it looked, it was what survives the agent moving to the next record. Criteria Form tab Custom page dialog Our choiceSide pane Readable at the same time as the case fields partial ✗ ✓ Survives navigating to the next case ✗ ✗ ✓ Width the agent can drag to suit their screen ✗ ✗ ✓ Keeps scroll position and open sections between records ✗ ✗ ✓ No change to the form layout to adopt it ✗ ✓ ✓ The side pane has been available in the Dynamics 365 app shell since 2021 and almost nothing in the standard app uses it beyond … Continue reading How to Extend Dynamics 365 CRM Using Side Panes: A Practical Implementation for a US-Based Kitchen Appliance Manufacturer →

Sending Dynamics 365 Emails from JavaScript with the Dataverse Web API | CloudFronts Summary Most Dynamics 365 emails are generated by workflows, Power Automate flows, or plugins reacting to a record change. But some notifications are triggered by a user action inside a custom UI, where the browser already holds all the context and the user needs to know immediately whether the email went out. In this implementation, we generated and sent Dynamics 365 email activities directly from JavaScript running in an HTML web resource, using only the Dataverse Web API. The email is created with sender and recipient activity parties, linked to a related record through the Regarding lookup, and sent through the SendEmail bound action for delivery by server-side synchronization. This article covers the problem, the use case, how an email is structured in Dataverse, and a step-by-step walkthrough of the JavaScript implementation, including the pitfalls we hit along the way. Table of Contents Problem Statement The Use Case Why Send Emails from JavaScript? Anatomy of an Email in Dataverse Solution Overview Step 1 — A Reusable Web API Helper Step 2 — Identifying the Sender Step 3 — Resolving the Recipient Dynamically Step 4 — Creating the Record the Email Will Be Regarding Step 5 — Composing the Subject and HTML Body Step 6 — Building the Activity Parties Step 7 — Binding the Regarding Lookup Step 8 — Creating the Email Record Step 9 — Sending the Email with SendEmail Understanding the Email Lifecycle The Complete Email Function Error Handling Testing and Validation Security and Production Considerations Key Implementation Lessons Conclusion Frequently Asked Questions This Blog Explains When a user action, rather than a record change, should be the trigger for an email. How an email activity, its activity parties, and its Regarding lookup fit together in Dataverse. How to create an email with From and To recipients through the Web API. The Regarding navigation property naming that commonly causes silent failures. The difference between creating an email and sending it. Why sent emails show as Pending Send, and what has to be configured for delivery. Read more about our Journey with this Customer over here: View Case Study  |  Refer my previous blog on the associated topic for more context Problem Statement Dynamics 365 offers several ways to send email automatically, and nearly all of them are record-driven: something is created or updated, and a workflow, flow, or plugin reacts to it. That model breaks down when the event worth notifying about is not a simple record change but an action a user performs in a custom interface, such as an HTML web resource or a custom page. In those cases: The trigger is a button click, and the relevant context (who acted, what changed, what the previous value was) lives in the browser. The email must only be sent once a multi-step operation has fully succeeded, not when it starts. The user expects immediate confirmation that the notification went out, or a clear message if it did not. The email should be a proper Dynamics 365 activity, visible on a related record’s timeline, not an untracked message sent from outside CRM. An asynchronous flow cannot give the user that immediate feedback, and a plugin would need to reconstruct context the UI already has. The question became: Can we create, link, and send a fully tracked Dynamics 365 email directly from the JavaScript that handles the user’s action, using only the Dataverse Web API? The Use Case The scenario was a custom Dataverse Choice (Option Set) Manager, an HTML web resource that lets authorized users add or relabel picklist values (for example, Lead Source) from within Dynamics 365.Building Self-Service Dataverse Choice Picklist values feed reports, business rules, flows, and integrations, so the Operations Lead needed to be informed every time one changed. The notification rules were: Rule Implication for the email Notify only after the change is published The email is generated as the final step, after PublishXml succeeds Send from the user who made the change The sender activity party is the signed-in user Send to whoever currently holds the Operations Lead role The recipient is resolved at runtime, not hard-coded Keep the email traceable The email is set Regarding a Picklist Changes Audit Log record Include full change details The HTML body lists action, time, user, entity, field, option name, value, and old label The picklist change itself is the trigger. Everything that follows in this article is about the email. Why Send Emails from JavaScript? Approach Fit for a user-action trigger Power Automate Runs asynchronously, so the user cannot be told in the same interaction whether the email was sent Classic workflow Record-driven and deprecated in favour of Power Automate for new development Plugin Needs a compiled, registered assembly and must reconstruct context the UI already holds JavaScript + Web API Runs in the same interaction, has full context, and reports success or failure to the user immediately Because the web resource runs inside Dynamics 365, each Web API call executes as the signed-in user. Their security roles still decide whether they can create an email, set its recipients, and send it. Anatomy of an Email in Dataverse Before writing any code, it helps to understand that an email in Dynamics 365 is not a single record with To and From text fields. It is an activity made up of several related pieces. email (activity) ├── subject ├── description → HTML body ├── directioncode → true = outgoing ├── statecode / statuscode │ ├── email_activity_parties (collection) │ ├── participationtypemask = 1 → From │ ├── participationtypemask = 2 → To │ ├── participationtypemask = 3 → CC │ └── participationtypemask = 4 → BCC │ └── partyid → systemuser / contact / account / lead … │ └── regardingobjectid → any activity-enabled table Piece What it does Email record Holds the subject, body, direction, and status Activity parties Separate records linking the email to each sender and recipient Regarding Polymorphic lookup … Continue reading D365 CRM – Generating Emails using JavaScript via user actions for US based Azure & AI services company →

Please find this CloudFronts Product at – CloudFronts PO-BC Integration Module | Microsoft Marketplace Watch the webinar – CloudFronts PO-BC Integration Webinar | YouTube Summary Dynamics 365 Project Operations (PO) holds customers, projects and time. Business Central (BC) holds invoices and payments. When the two are not connected, people copy data by hand, which is slow and causes mistakes. The CloudFronts PO-BC Integration Module is a Dynamics 365 Project Operations and Business Central integration. You set up the link once, and every change in PO shows up in BC automatically. The result is no double typing, fewer mistakes and faster billing. This blog shows how it works, step by step. Table of Contents 1Introduction 2Business Challenge 3Why an Integration Hub? 4Implementation Procedure 5End-to-End Working 6Why This Approach Works 7Real-World Use Cases 8Frequently Asked Questions 9Conclusion Introduction: Why Connect Dynamics 365 Project Operations with Business Central Many project-based businesses use two systems. Project Operations (PO) is where the sales and project teams keep customers, projects and time. Business Central (BC) is where the finance team keeps invoices, payments and money records. Both systems need the same details. A customer made in PO must also exist in BC. A project made in PO must also be there when it is time to send an invoice. Without a link, someone has to copy all of this by hand. Here is the full picture of how work moves from a lead to a payment. The top row is PO and the bottom row is BC. The arrows show where the two systems share data. The full flow from lead to payment, and where PO and BC share data. The Solution: We built an Integration Hub. It is a simple web app where you connect PO and BC, set the rules once, and let the data move on its own. Business Challenge: Manual Data Entry Between PO and BC Think about a normal project business. The sales team makes a customer in PO. The project team makes a project and adds tasks. The finance team then needs the same customer and project in BC to send invoices. These details need to be shared between the two systems: Customers and contacts Projects and tasks Planned work and costs Approved time and expenses Vendor invoices and purchase orders Paid status of invoices When people copy these by hand, many problems come up: Extra effort: The same details are typed in two systems. Mistakes: A wrong phone number or address is easy to type. Details that do not match: The two systems slowly stop agreeing with each other. Late invoices: If data reaches finance late, money comes in late. Hard to grow: More customers and projects mean more copying and checking. The Objective: When something changes in PO, BC should get the change by itself. No one should have to copy anything by hand. Why Use an Integration Hub for PO and BC Integration? The Integration Hub is one place where you create and manage every link between PO and BC. You fill a form, choose what to send, and set simple rules. You do not need to write a lot of code. With the Integration Hub, you can: Set up each link once Choose what data moves, from where, and to where Write simple rules for which detail goes where Test the result before it goes live See all links in one list, with their status and last runs Add new links as your business grows In simple words: Think of the Integration Hub as a control room. From here you decide what data moves, from where, and to where. Implementation Procedure: How to Integrate Project Operations with Business Central Step 1 – Choose the Project On the first screen you pick a project. A project here is a group of links. We use the project named PO-BC, which is for Project Operations and Business Central. Choose the project. We are using PO-BC. Step 2 – See the List of Integrations Inside PO-BC you can see all the links. Each row shows its order number, its status, and its last few runs. You can run, edit or deploy each one from here. To add a new one, click New Integration. The list of integrations. Click New Integration to add one. Step 3 – Fill the New Integration Form A form opens on the right side. Here you tell the platform: Integration Name: A name for this link. For example, Accounts. Integration Type: Master means basic details that rarely change, like customers. Transactional means things that happen often, like invoices. Source System and Source Entity: Where the data starts, and what kind of record it is. Here the system is PO, and the record type is accounts. Target System and Target Entity: Where the data goes, and what kind of record it becomes. Here the system is BC, and the record type is customer. Sequence No.: The order in which links run. Customers must exist first, so this is 1. The new integration form. Use Sync CRM Fields to add any missing fields that BC needs on the PO side. Tip: There is a handy button called Sync CRM Fields. Sometimes BC needs a detail that PO does not have yet. This button creates the missing field in PO for you. Scroll down and add a short description. This helps everyone understand later what the link does. Then click Create Integration. Add a clear description, then click Create Integration. Step 4 – Open the Flow After you create the link, you can open its flow. It is a simple picture with boxes from left to right: Source: the PO data (accounts) Data Mapper: the rules that change the data into the shape BC needs Target: the BC data (customer) Return to Source: an optional step to send data back to PO The flow. The Data Mapper box is where we set the rules. Step 5 – Write the Mapping Rules PO and BC use different names for … Continue reading Dynamics 365 Project Operations and Business Central Integration: Automate Data Sync Without Manual Work →

At a Glance Company profile Infrastructure developer with legal entities in India, Southeast Asia and Europe Challenge Run all entities on one Business Central platform, managed from India, while meeting each country’s tax rules Question asked “Can we use only Indian localisation and handle the other countries’ taxes outside the system?” Options evaluated One production environment (India localisation and external tax) vs two production environments (local localisation) Recommendation Two production environments: one India, one Group (W1 base with a partner localisation) Key takeaway Localisation is an environment-level decision, and the hardest one to reverse after go-live Table of Contents Summary The Situation How Localisation Actually Works in Business Central Online Option 1: One Production Environment with External Tax Calculation Option 2: Two Production Environments with Local Localisation Side-by-Side Comparison The Cost Question Our Recommendation A Checklist Before You Decide Conclusion Frequently Asked Questions Summary Most multi-country ERP conversations start with modules: finance, procurement, projects, consolidation. But for groups operating across several tax jurisdictions, one of the earliest decisions matters more than any module choice. Where will each company live, and which localisation will it use? In Business Central online, that decision is easy to underestimate. It looks like a technical setup detail. In practice, it shapes your invoices, your tax returns, your intercompany design and your audit trail for as long as you run the system. Recently, one of our prospect, an infrastructure developer with entities in India, Southeast Asia and Europe, asked us a direct question: “Our finance team sits in India. Can we run every company on Indian localisation and handle the other countries’ taxes outside the system?” This blog walks through how we evaluated that question and what we recommended. The Situation The prospect was moving off separate accounting systems (a different package for each entity) with manual consolidation. Their requirements were clear: Several legal entities, with a holding entity planned above them. Different functional currencies and financial years. India runs April–March, while the other entities run January–December. Different reporting standards: Ind AS, IFRS and SFRS. Two-level consolidation. One central finance team in India managing all entities. Local tax compliance in each country: GST and e-invoicing in India, VAT in Europe, and GST with mandatory e-invoicing in Southeast Asia once registered. Running everything from India made Indian localisation feel like the natural default. The question was whether that default would hold up for the non-Indian entities. How Localisation Actually Works in Business Central Online Before comparing options, it helps to be clear on three points that often surprise finance teams. 1 Localisation is set per environment, not per company. Every company inside a Business Central online environment uses that environment’s localisation. That covers the tax engine, statutory reports and country-specific fields. You can create a Singapore or Cyprus company inside an India environment, but it will behave like an Indian company. 2 Microsoft doesn’t localise every country. Microsoft provides its own localisation for 21 countries, including India, Australia, New Zealand, the UK, the US and much of Western Europe. Many other markets, including Singapore and Cyprus, are served by partner localisation apps on AppSource, installed on Microsoft’s base version (W1). 3 Localisation is free, but environments aren’t. Microsoft doesn’t charge for localisation itself. A tenant includes one production environment. Every additional production environment needs an add-on subscription. Important Changing a company’s localisation after go-live means migrating it to a new environment, then re-testing and re-validating it. Getting this right at the design stage avoids expensive rework later. Option 1: One Production Environment with External Tax Calculation In this model, every company sits in a single environment on India localisation. Tax for the non-Indian entities is calculated in an external tool, and the amounts are brought into Business Central through an integration. What it involves: Switching off India-specific GST/TDS behaviour for the non-Indian companies. Custom invoice and credit-note layouts without India tax fields. An extension to post externally calculated tax amounts, so document totals match the original invoice. An API integration with the external tax tool, plus middleware and error logging. A custom e-invoicing integration (for example, Peppol / InvoiceNow) when it becomes mandatory. Pros One environment to administer. Simpler intercompany and consolidation, with no cross-environment setup. No additional production environment subscription. No partner localisation apps to license. Cons Tax returns are prepared outside Business Central, so they don’t tie directly to the ledger. More custom code to build, test and maintain through every Microsoft update. Two systems to reconcile every period. E-invoicing depends on an access-point provider supporting a non-standard setup. Higher audit exposure, and costly to reverse later. Option 2: Two Production Environments with Local Localisation In this model, the Indian entity sits in an India environment on Microsoft’s India localisation. All other entities sit in a Group environment on the W1 base, with a partner localisation app where needed and standard VAT configuration for the European entity. Intercompany and consolidation between the two environments use Business Central’s standard cross-environment features. Pros Each country’s tax is calculated and posted in Business Central. Local returns and audit files tie directly to the ledger. Invoices follow each country’s format, with no foreign tax fields. E-invoicing is supported through standard partner apps. Less custom code and lower upgrade risk. The same user licence works across both environments, so central finance in India is unaffected. Cons An additional production environment subscription. Partner localisation app subscriptions. Cross-environment intercompany needs experienced setup and testing. Two environments to administer (updates, sandboxes, permissions). Side-by-Side Comparison Area One Environment (India + external tax) Two Environments (local localisation) Production environments 1 2 Non-Indian tax Calculated outside BC, amounts integrated Calculated in BC Local tax returns Prepared outside BC Generated from BC Invoice compliance Custom layouts Standard local formats E-invoicing Custom integration Partner app Intercompany Same environment (simpler) Cross-environment (standard feature) Custom development Higher Lower Audit and upgrade risk Medium–High Low Reversibility Costly migration later Already correct The Cost Question At first glance, the single-environment option looks cheaper because it avoids the additional environment and the … Continue reading How a Multi-Country Infrastructure Group Evaluated One vs Two Production Environments in Dynamics 365 Business Central →

Summary An Australian commercial laundry and linen company already sent its quotes from Dynamics 365, with Approve and Reject buttons in the email. It worked, but the links never expired and could be clicked again and again, so a forwarded or months old email could still change a quote. We made every link single use and valid for 30 days. Customers still answer with one click, and the sales team can now trust the decision they see on the quote. In This Blog Why a reusable approval link is a quiet business risk What the customer sees, from email to confirmation What the sales team sees in Dynamics 365 How we went live without breaking quotes already sent When this approach is the right fit Table of Contents Summary→ Business Challenges→ What We Built→ How It Works→ Going Live Safely→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges The quoting process itself was in good shape. Sales built the quote in Dynamics 365, generated the PDF and emailed it with two buttons. The customer clicked Approve or Reject and the answer landed on the quote. Nobody had to chase a reply or retype it. The weak spot was the link behind those buttons. It never changed and never expired, and anyone holding the email could use it. In practice that meant: A customer could approve a quote, then click Reject on the same email weeks later and quietly overwrite the decision. An email forwarded inside the customer’s business could be answered by someone who was never meant to decide. Quotes that had been revised and resent still had live buttons in the older emails. For a business that moves straight from an approved quote to a contract, the decision on the record has to be the real one. Before Links worked forever Any click could change the answer Old emails stayed live after a resend After Each link works once, for 30 days The first decision is final Only the newest email is live What We Built For the customer, almost nothing changed, which was the point. The email looks the same, with the quote attached and the two buttons underneath. There is still no login, no portal and no password to remember. The quote email with the PDF attached and one click Approve and Reject buttons. Captured from a test quote, names changed. One click records the decision and shows a short confirmation. When the quote is approved, the page tells the customer the contract is on its way. The confirmation the customer sees after approving. Captured from a test quote. What changed is everything after that first click. If a button is clicked again, the customer is told the quote is already approved and nothing on the record moves. If the link is older than 30 days, or a newer quote email has replaced it, a clear page asks them to contact their sales representative for a fresh link. Clicking the same link again changes nothing and says so plainly. Captured from a test quote. An expired or replaced link points the customer back to their sales contact. Inside Dynamics 365, the customer.s decision is saved straight onto the quote, along with when the link expires. That decision is what starts the contract process, so it now carries real weight. The test quote in Dynamics 365. The timeline confirms the quote document was sent for review and approval. Names changed. How It Works Everything runs on Dynamics 365 and Power Automate, which the client already had. No new apps and no new licences. Step oneSales sends the quoteFrom the quote, as before Step twoA unique link is issuedOne per email, valid for 30 days Step threeThe customer clicksThe link is checked before anything is saved Step fourDecision saved, link closedAny later click is politely turned away How a quote link moves from sent, to used or expired. Each time a quote is sent, Dynamics 365 stores a new private code and an expiry date on the quote, and that code is built into both buttons. When the customer clicks, the flow compares the code in the link with the one on the quote. Only a match within 30 days is accepted. Once the decision is saved, the code is marked as used, so the same link cannot be accepted again. Worth knowing before you start Resending a quote replaces the link, so customers should always act on the newest email. Agree the expiry period with sales up front: 30 days suited this client’s quoting cycle, but yours may be shorter. And make sure the expired page names someone the customer can actually contact. Going Live Safely The tricky part was not the new links. It was the quotes already sitting in customers’ inboxes, sent under the old process without a private code. Switching them off overnight would have turned a security improvement into a stream of confused customers. So those older emails keep working until each quote receives its first answer, and from then on the same single use rules apply. We built and tested in the client’s test environment first, then went live in production with test quotes sent only to our own team before any customer saw the change. Impact A decision you can trust. The answer on the quote is the customer’s first and final one, so contracts start from solid ground. No extra effort for customers. Still one click, still no login, on any phone or laptop. Old emails retire themselves. Revised quotes no longer leave live buttons behind. No new cost. Built on the Dynamics 365 and Power Automate licences the client already owned. Is This Right for You? There is more than one way to collect a customer’s yes. This is how we usually compare them with clients. This projectOne time email link Customer portal Electronic signature Customer effort One click, no login Sign in, then respond Open, review and sign Extra licences None Portal … Continue reading How an Australian Linen Company Made Quote Approvals Secure with One Time Links in Dynamics 365 →

Summary An Emirates-based marine services firm running Microsoft Dynamics 365 Business Central found that an approved purchase order had disappeared, along with every record of who approved it. We confirmed the order had been deleted rather than archived, showed why Business Central removes approval entries together with the document, and identified the likely approvers from the approval chain. We then explained how a point-in-time restore of Production into a sandbox recovers the actual approval history, set up the change log so future deletions are recorded in full, and recommended controls that stop approved documents from being deleted at all. Table of Contents Introduction Understanding the Issue Deleted or Archived? How We Confirmed It Why the Approval Entries Disappeared Reconstructing the Likely Approvers Recovering the Evidence with a Point-in-Time Restore Making Future Deletions Traceable Preventing Approved Documents from Being Deleted Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows in Microsoft Dynamics 365 Business Central give finance teams confidence that every purchase order was reviewed before it went to a vendor. That confidence depends on one assumption: the approval history will still be there when someone needs it. For an Emirates-based marine services firm we work with, that assumption broke. The finance team went looking for a released purchase order and could not find it. When they checked Approval Entries, there was nothing there either. A few days later, two purchase invoices were deleted as well, and the change log had no record of them. 1 Approved purchase order missing 0 Approval entries left for it 28 Days available to recover the evidence This post walks through how we investigated the issue, what Business Central does behind the scenes when a document is deleted, and the setup that makes every future deletion traceable. The Lesson In Business Central, deleting a document also deletes its approval history. Audit trails have to be set up before they are needed, not after. Understanding the Issue The finance team came to us with three questions. Each needed a clear, evidence-based answer. 01 Was It Deleted or Archived? The order was in Purchase Order Archives, so it looked as if someone had simply archived it by hand. 02 Who Approved It? The order had been released through an approval workflow, but Approval Entries showed nothing for it. 03 Why Was Nothing Logged? The change log had just been switched on, yet the invoices deleted afterwards left no trace in it. Deleted or Archived? How We Confirmed It Archiving and deleting both leave a copy in Purchase Order Archives, so the archive alone does not tell you what happened. The difference is what remains in the live system. Archived Archive Document A copy is saved to Purchase Order Archives, but the original order stays in the Purchase Orders list, together with its approval entries. Deleted Delete The order leaves the Purchase Orders list. If Purchases & Payables Setup is set to archive orders, Business Central saves an archive copy automatically at the moment of deletion. We worked through the possibilities one at a time: How we ruled out each possibility Not in Purchase Orders → No Receipts, Invoices or G/L Entries → Only in Archives → Version No. 1 → Deleted The Version section of the archived order settled it: Version No. 1: only one archived version existed, so the order had never been archived by hand. This version was created when the order was deleted. Archived By: the user ID that deleted the order. Date and Time Archived: the exact moment of deletion. Figure 1: The archive version details show who deleted the order and when. Why the Approval Entries Disappeared Approval entries are linked to the document they belong to. When the document is deleted, Business Central deletes its approval entries too. The archive keeps the order’s header and lines, but not its approval history. To show this to the client with evidence rather than theory, we reproduced it on a copy of Production using an older released order: 1 Released Order We picked a purchase order that had been released through the approval workflow. 2 Approvals Recorded Its Approval Entries showed three approvals from three different approvers. 3 Order Deleted After the order was deleted, Approval Entries showed nothing for it. 4 Archive Copy Remains The order was still available in Purchase Order Archives, without its approvals. Figure 2: Before deletion, the test order carries its full approval history. Figure 3: After deletion, the approval entries are gone, even though an archive copy exists. Key Insight Purchase Order Archives answer what the order looked like. They do not answer who approved it. Once a document is deleted, that question can only be answered from a backup. Reconstructing the Likely Approvers With the approval entries gone, we looked at the next purchase order raised by the same user. Approvals follow the approver chain set up in Approval User Setup, so an order from the same requester with a similar amount follows the same route. Step Role What Happens 1 Requester Raises the purchase order and sends it for approval 2 First approver Next user in the requester’s approver chain 3 Second approver Next user in the chain, based on the approval limits A Reconstruction, Not a Record This identifies the most likely approvers, but it is not proof. It assumes the approval setup has not changed since, and that the deleted order’s amount did not cross a limit that would have added another approver. Recovering the Evidence with a Point-in-Time Restore Business Central Online lets you restore an environment to any point in time within the last 28 days. A Production environment can be restored as a new sandbox, which leaves Production untouched. In that copy, the deleted order still exists with all its approval entries. Steps We Recommended In the Business Central Admin Center, open the Production environment and choose Restore. Pick a point in time a few minutes before the deletion. Convert the archive’s timestamp to the time zone the Admin Center … Continue reading Recovering Lost Approval History After a Purchase Order Deletion in Business Central →